pwd: fix hostname resolution on macos #7029
Conversation
When macOS's "Private WiFi address" feature is enabled it'll change the hostname to a mac address. Mac addresses look like URIs with a hostname and port component, e.g. 12:34:56:78:90:12 where `:12` looks like port 12. However, mac addresses can also contain letters a through f, so a valid mac address like ab:cd:ef:ab:cd:ef is valid, but will not be parsed as a URI, because `:ef` is not a valid port. This commit attempts to fix that by checking if the hostname is a valid mac address when `std.Uri.parse()` fails and constructing a new std.Uri struct using that information. It's not perfect, but is equally compliant with the URI spec as std.Uri currently is.
There was a problem hiding this comment.
Two quick thoughts:
- This is probably getting complicated enough to warrant a separate utility function (with tests), perhaps outside of the stream handler.
- I'm starting to feel like we should follow Kitty's example and treat the
file://andkitty-report-cwd://schemes differently: onlyfile://URLs get the encoding. (See elvish: use kitty-shell-cwd:// to report pwd #7033)
100% agree, I had the same thought as I was working on this. I haven't confirmed the fix though so I figured I'd make a quick and dirty version that I could test, and clean it up later. And yep, that includes a separate function, tests, the whole thing 🙂
Yeah, we probably should. Or at the very least we probably shouldn't be using For example, |
|
It seems to me that this would be better solved on the macOS level. Either by using |
I think the main problem is that posix.gethostname() - the hostname we compare to whatever the shell integration passes to us - returns the mac address version of the hostname. I suppose we could run And either way I think we should treat mac addresses as valid hostnames, even if they're not compliant with the general linux hostname spec of |
Note
This is still a draft. The problem is tedious to reproduce, but this should fix it. Once I've confirmed that this addresses the issue I'll clean up the PR and mark it as a non-draft
Description
Yet another edge case in #2484
When macOS's "Private WiFi address" feature is enabled it'll change the hostname to a mac address. Mac addresses look like URIs with a hostname and port component, e.g.
12:34:56:78:90:12where:12looks like port12. However, mac addresses use hex numbers and as such can also contain lettersathroughf. So, a mac address likeab:cd:ef:ab:cd:efis valid, but will not be parsed as a URI, because:efis not a valid port.This commit attempts to fix that by checking if the hostname is a valid mac address when
std.Uri.parse()fails and constructing a newstd.Uristruct using that information.It's not perfect, but is equally compliant with the URI spec as
std.Uricurrently is. Meaning not at all compliant 😅Testing instructions
Important
You must be connected to WiFi to be able to test this.
Setup - Enable the "Private WiFi address" setting
Rotating.Important
Now you wait. The private Wi-Fi address will eventually rotate to a mac address that ends with a non-digit, e.g.
0a,ff,e2, etc. You'll notice this when your shell integration stops working, e.g. you open a new tab in Ghostty and the shell is in your home directory instead of whichever directory you had open in your previous tab.Testing the changes
cdto any directory that isn't the default (usually$HOME) directory, e.g.cd Documents.main: land in$HOMEin the new tab or split.